Mitigating automated attacks in a computer network environment

ABSTRACT

A technique to slow down or block creation of automated attack scripts uses a detector configured to discriminate whether particular attack-like activity is a true attack, or simply a hacker “testing” an automated attack script, and then permitting any such test script to continue working (attacking) the site, albeit on a limited basis. In this manner, the hacker receives an indication that his or her automated attack script is already working. Thereafter, when the detector later detects a launch of an actual attack based on or otherwise associated with the automated attack script (previously under test), the attack fails either because the script was not a working script in the first instance, or because information learned about the script is used to adjust the site as necessary to then prepare adequately for a true attack.

BACKGROUND Technical Field

This application relates generally to protecting websites and mobileapplications (apps) from automated attacks by scripts or bots.

Brief Description of the Related Art

Over a billion user credentials (usernames, passwords, email addresses)were stolen during large breaches in 2014 and 2015. Hackers are nowmonetizing those stolen credentials across a wide range of popular weband mobile services. E-commerce, e-banking, online sharing, socialnetworks, travel web sites, online ticketing, educational services,healthcare, insurance, gaming, etc. have become targets of the use ofstolen credentials. Hackers know that people commonly reuse theircredentials across the web. Most people use about threeusernames/handles and have two to three passwords. They exploit thisknowledge by writing a variety of sophisticated scripts exercisingmultiple attack vectors to compromise popular web properties. Theseautomated attacks are known variously as malicious bots or maliciousscripts.

There are many significant challenges in detecting attacks with stolencredentials. Often the credentials themselves are legitimate. Hackersalso hide within regular web and mobile user traffic by attacking duringnormal service hours and distributing attacks from commonly used deviceswith IP addresses across multiple geographic regions. It is increasinglydifficult for many of the usual checks/detection methods to distinguishbetween real customers and attackers. Hackers adapt and changecontinuously, rotating through their arsenal of attack vectors, scripts,and/or deployment schemes, allowing them to evolve against standarddetection schemes.

Current methods to deter and block attacks include employing Captchas,device identification, browser identification, IP address tracking, andnetwork log analysis. While these approaches provide significantbenefits, there remains a need in the art to provide new techniques,especially with respect to mitigating unauthorized automated attacks,which remain a significant problem for websites and mobile apps,primarily because an attacker can easily create and test his attackscripts before deploying a large scale attack.

BRIEF SUMMARY

This disclosure describes a technique to slow down or block creation ofthese attack scripts in the first instance. To this end, and accordingto this disclosure, a detector is configured to discriminate whetherparticular attack-like activity is a true attack, or simply a hacker“testing” his or her automated attack script. This discrimination iscarried out based on one or more detection mechanisms, such astransaction rate checks, analytical checks, user history checks,aggregate analysis, IP location checks, and other behavioral checks.Machine learning may be used to facilitate this process and the attackversus test detection. Upon a determination that an automated attackscript is being tested, and in lieu of blocking the automated attackscript, the detector actually permits the test script to continuerunning, e.g., by providing limited access to a resource on the site. Inthis manner, in effect the hacker receives a false indication that hisor her automated attack script is already working. Thus, when thedetector later detects a launch of an actual attack based on orotherwise associated with the automated attack script (previously undertest), the attack fails either because the script was not a workingscript in the first instance, or because information learned about thescript is used to adjust the site as necessary to then prepareadequately for a true attack.

The foregoing has outlined some of the more pertinent features of thesubject matter. These features should be construed to be merelyillustrative. Many other beneficial results can be attained by applyingthe disclosed subject matter in a different manner or by modifying thesubject matter as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the subject matter and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 shows a typical client-server configuration where a human beingis performing an authorized action on a website/mobile app;

FIG. 2 depicts a malicious situation where a script is being used toperform an automated action;

FIG. 3 depicts a large scale attack where the malicious script used inFIG. 2 is deployed across multiple computers;

FIG. 4 depicts a configuration where a security tool is deployed on aseparate threat detection and response server to protect the site orapplication;

FIG. 5 depicts an alternative configuration where the security tool isdeployed as being integrated with the web/mobile server itself;

FIG. 6 depicts augmenting a threat detector with an attack versus testdetector tool to facilitate the mitigation technique of this disclosure;

FIG. 7 depicts an alternate embodiment wherein the attack versus testdetector is integrated with a decision unit;

FIG. 8 depicts another yet alternative embodiment wherein the threatdetector is integrated with the decision unit, and wherein the attackversus test detector is operated in a standalone manner;

FIG. 9 depicts yet another alternative embodiment of the security toolimplementation of this disclosure; and

FIG. 10 depicts processing modules that may be used in the detector ofthis disclosure.

DETAILED DESCRIPTION

By way of background, and as used herein, the notion of an “actualattack” relates to an act of running large scale automated activity(e.g., testing millions of login/password combinations). In contrast, a“testing phase” relates to a process in which the attacker creates ascript and then tests its efficacy. This notion is sometimes referred toherein as a “script-under-test.” For example, the script may be anautomated program that can successfully login using valid/testcredentials. Typically, an attacker engages in the testing phase priorto the actual attack to ensure the script successfully works; otherwise,it is a significant waste of resources (and a wasted expense) for anattacker to deploy an actual attack with a non-working script. Thetesting phase can also be called training or any other term to describethe process of creating a working script.

As is well-known, automated activity may include form transactions(e.g., logins, signup, payments transactions), clicking, or even simplenavigations (web-scraping, or the like). To simplify the followingdescription, the technique herein is described in the context of anexample embodiment of logging into a website. This embodiment, however,is merely representative, as the mitigation technique herein may be usedirrespective of the type of automated attack vector.

Creating a “working” login script typically involves two steps. First,the script should be able to functionally login to a website in anautomated fashion without any human assistance. A known technique oftenexploited is application programming interface (API) reverse-engineeringon the part of the attacker, and directly passing credentials to the APIinterface. A more advanced technique might involve going through thefull web-experience, e.g., by using a headless browser or other tools.Second, and apart from being able to functionally pass credentials, thescript needs to be able to circumvent or bypass security technologies.If a security tool detects an automated login, typically it will blockthe script by either rejecting the login (even if the credentials arevalid), or by asking for additional verifications (e.g., solving a test,such as a test using the Captcha™ technology). As is well-known,Captcha™ technology is a program or system intended to distinguish humanfrom machine input, typically as a way of thwarting spam and automatedextraction of data from websites. A “working” login script thus alsoneeds to be able to successfully fool a security tool and not getdetected by such security technology. An attacker of course can tweak,train, or test the script until he or she has achieved this goal.

The technique of this disclosure, however, is designed to convince theattacker that such further tweaking, training or testing is no longerrequired. Thus, the notion here in effect is to fool the attacker intobelieving that the script-under-test is actually working and, as aconsequence, does not necessarily need further refinement. In this way,the system can learn and adapt its security measures appropriately.

To this end, the embodiments described herein use an approach to confusethe attacker during this second step (the testing phase). In oneembodiment, a security tool (e.g., a threat detector, a threat detectionand response server, etc.) detects and distinguishes an actual attackfrom the testing phase. When the security tool detects testing phaseactivity, and instead of blocking the attacker, the security tool letsthe attacker through. This gives an artificial illusion to the attackerthat he or she has a working script. Then, when an actual attack islater launched, the attack is blocked easily either because the scriptwas not a working script in the first place, or because the site isadapted in advance as necessary to then block the actual script. Thelatter situation may be implemented for example when the test scriptexhibits some degree of efficacy. In this manner, and in addition to thevalue of blocking the attack, the security tool slows down or blocks theattacker from developing a successful working script.

The operations of the security tool can be implemented in variousconfigurations other than in a threat detector, or threat detection andresponse server. For example, the security tool can be deployed in a webserver or a mobile server. More generally, the security tool of thisdisclosure may be implemented as processing logic that may comprisessoftware, firmware, hardware, or any combination thereof.

FIG. 1 shows a typical client-server configuration where a human being100 is performing an authorized action from his or her client machinebrowser 102 or mobile device app 104 with respect a web/mobile appserver 106. FIG. 2 depicts the same scenario but instead shows amalicious script 200 is being used to perform an automated action (e.g.,via the client machine browser or mobile device app) on the remoteweb/mobile app server 206. Creation of an attack script is typicallydone in this configuration. A larger attack can also be done by runningthe script repetitively with high frequency. As previously noted, thistype of automated activity can be very damaging, especially if thehacker learns that his or her test script is efficacious. To that end,FIG. 3 depicts a large scale attack where the malicious script used inFIG. 2 is deployed across multiple computers 300, and among otherserious security problems, this type of attack can lead to adenial-of-service at the web/mobile app server 306.

FIG. 4 depicts a known configuration where a security tool 405 isdeployed on a separate threat detection and response server 400 toprotect the site/mobile app server application 406. In this examplescenario, the security tool is deployed in a co-located manner, but thisis not a limitation, as the security tool operations may be carried as amanaged service (e.g., in a cloud-based environment) by a serviceprovider dedicated to provide such service, by a third party (e.g., acontent delivery network (CDN) service provider, or the like. FIG. 5depicts an alternative configuration where the security tool 505 isdeployed as being integrated with the web/mobile server 506 itself.Typically, the security tool is implemented as computer software (one orcomputer programs executed in one or more hardware processors).

FIG. 6 depicts conventional processing of the security tool 600 withrespect to an incoming transaction 602. The notion of a transaction heretypically refers to one or more actions initiated by the automatedscript, e.g., an HTTP request for a particular resource, an operationtriggered by scripting code, an AJAX request-response interaction, orany other activity initiated from the client and directed to the server.In a conventional system such as described above, the transaction isprocessed by a threat detector, and a decision is returned based on thelikelihood that the transaction is a threat. Techniques fordiscriminating human versus automated script behavior are described, forexample, in commonly-owned U.S. Pat. No. 9,639,699, titled “Detectingnon-human users on computer systems,” the disclosure of which isincorporated herein by reference. According to this disclosure,preferably the security tool threat detector 600 is paired with anattack versus test detector process/module 604 and a decision entityprocess/module 606 In operation, the attack versus test detector 604determines whether the transaction 602 is coming as part of an actualattack (such as that in FIG. 3), or whether it is a training/testingattempt on part of the attacker. Based on this determination, thedetector 604 notifies the decision unit 606 accordingly. The decisionunit 606 takes in the input from both the threat detector 600 and fromthe attack versus test detector 604. If it is determined that this is atest/training transaction, the decision unit 606 may choose not to blockor otherwise flag the transaction (unlike a conventional system thatwould block/flag the transaction). Accordingly, the attacker obtains ordevelops the false notion that he or she has a working attack script.Thus, when the attack script is deployed later in an actual attack (suchas that in FIG. 3), the attack versus threat detector 604 then marks thetransaction as an actual attack. The decision unit 606 then takes thisinformation and blocks or otherwise mitigates the transaction.

In this manner, the security tool thus slows down, confuses, or blocksthe attacker from testing or training in a manner that would beeffective (to the attacker).

FIG. 7 depicts an alternate embodiment of an implementation of thesecurity tool shown in FIG. 6. In this embodiment, the attack versustest detection and then decision unit are integrated into a combinedunit 700, which also receives the output generated by the threatdetector 702. Thus, the threat detector 702 first performs threatanalysis, followed by the attack versus test detector analysis. FIG. 8depicts yet another alternative embodiment of an implementation of thesecurity tool, wherein the attack versus test detector 800 operatesfirst and in a standalone manner. The output is then provided to acombined threat detector/decision unit 802. FIG. 9 depicts yet anotheralternative embodiment. In this embodiment, and like in FIG. 6, thethreat detector 900, the attack versus threat detector 902, and thedecision unit 904 operate independently, with the decision unit 904augmented to receive other conventional components 908 to facilitate thedecision making. These other components include, without limitation,knowledge sources, databases, expert systems, and the like.

FIG. 10 shows a detailed view of an embodiment of various processingmodules that comprise the attack versus test detector 1000. Theseprocessing modules are exemplary, and one or more of them may be used.As noted above, the attack versus test detector 1000 determines whetherthe transaction is part of an attack, or rather just a training/testattempt. The method or sub-modules that facilitate this determinationinclude, a transaction rate check 1002 that can be applied to see thefrequency of incoming transactions. A higher frequency is indicative ofan attack vs a training/test attempt. A user history check 1004 can beapplied to see patterns from the specific user. An IP/Location historycheck 1006 can be applied to see a history of training/testing activityand other malicious behavior. Additionally, evidence of multiple IP'ssending malicious transactions is indicative of an actual attack.General behavioral checks 1008 can be applied on various flags, and amodule 1010 may also perform one or more custom analytical checks 1012.The output(s) from these various sub-modules preferably are sent to anaggregate analysis sub-module/unit 1012. Unit 1012 usesstatistical/machine learning or other artificial intelligence techniquesto classify the transaction either as an actual attack or, instead, atest/training attempt. Representative analysis technique may include,among others, nearest neighbor, Manhattan distance, Euclidean distance,neural networks, fuzzy logic, k-means, support vector machines (SVM) orother statistical/pattern matching/machine learning techniques.

The transaction rate check 1002 is described in more detail with anexample of a possible implementation. In particular, the systemmaintains a counter or counters that a) increment based on certainevents, and b) get reset at periodic intervals. Preferably, the counteris incremented when a scripted login is detected. Optionally, multipleparallel counters can be created, and where a signature/pattern isassociated with each counter. The signature/pattern can be based on thescript device fingerprint or other behavioral attributes (e.g.,mouse/keystroke characteristic of the script). Assuming there aremultiple counters (each with an associated signature), the counter thatis associated with the training script is incremented at a much lowerrate, as the attacker is just testing the script. Periodically, thecounter is reset (with the periodic interval being configurable). At anypoint of time, the value of the counter is compared to a programmablethreshold. If the value exceeds the threshold, this implies an actualattack has been initiated; otherwise, it is a training attempt.Resetting the counter at periodic intervals ensures the counter for atraining attempts does not artificially hit the threshold.

The user history check 1004 is described with an example of a possibleimplementation. During the training process the attacker typically usescredentials that he/she personally created as a throwaway account. In aprior training session, the system (e.g., using technique 1002) may havedetected the training attempts and. at that point, this module tabulatesthe user credentials used in the training activity. These usercredentials are then stored in a table as attacker credentials.Subsequently, and in a new training phase, if the module then seesmultiple hits to this table the system marks this as a training phaseand not a real attack.

Of course, the above techniques are merely exemplary.

Other statistical, probabilistic or combined techniques may beimplemented to facilitate the attack versus test determination.

A given attack versus test determination may have a confidence level (orweight) associated therewith. The type of response generated by thedecision unit may also be based on the confidence level value and itsrelationship to one or more confidence levels, which levels may bepre-configured or hard-coded.

Enabling Technologies

The techniques herein may be implemented in a computing platform, suchas variously depicted in FIGS. 6-9, although other implementations maybe utilized as well. One or more functions of the computing platform maybe implemented conveniently in a cloud-based architecture. As iswell-known, cloud computing is a model of service delivery for enablingon-demand network access to a shared pool of configurable computingresources (e.g. networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. Available services modelsthat may be leveraged in whole or in part include: Software as a Service(SaaS) (the provider's applications running on cloud infrastructure);Platform as a service (PaaS) (the customer deploys applications that maybe created using provider tools onto the cloud infrastructure);Infrastructure as a Service (IaaS) (customer provisions its ownprocessing, storage, networks and other computing resources and candeploy and run operating systems and applications).

The platform may comprise co-located hardware and software resources, orresources that are physically, logically, virtually and/orgeographically distinct. Communication networks used to communicate toand from the platform services may be packet-based, non-packet based,and secure or non-secure, or some combination thereof. More generally,the techniques described herein are provided using a set of one or morecomputing-related entities (systems, machines, processes, programs,libraries, functions, or the like) that together facilitate or providethe described functionality described above. In a typicalimplementation, a representative machine on which the software executescomprises commodity hardware, an operating system, an applicationruntime environment, and a set of applications or processes andassociated data, that provide the functionality of a given system orsubsystem. As described, the functionality may be implemented in astandalone machine, or across a distributed set of machines.

Each above-described process, module or sub-module preferably isimplemented in computer software as a set of program instructionsexecutable in one or more processors, as a special-purpose machine.

Representative machines on which the subject matter herein is providedmay be Intel Pentium-based computers running a Linux or Linux-variantoperating system and one or more applications to carry out the describedfunctionality. One or more of the processes described above areimplemented as computer programs, namely, as a set of computerinstructions, for performing the functionality described.

While the above describes a particular order of operations performed bycertain embodiments of the disclosed subject matter, it should beunderstood that such order is exemplary, as alternative embodiments mayperform the operations in a different order, combine certain operations,overlap certain operations, or the like. References in the specificationto a given embodiment indicate that the embodiment described may includea particular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

While the disclosed subject matter has been described in the context ofa method or process, the subject matter also relates to apparatus forperforming the operations herein. This apparatus may be a particularmachine that is specially constructed for the required purposes, or itmay comprise a computer otherwise selectively activated or reconfiguredby a computer program stored in the computer. Such a computer programmay be stored in a computer readable storage medium, such as, but is notlimited to, any type of disk including an optical disk, a CD-ROM, and amagnetic-optical disk, a read-only memory (ROM), a random access memory(RAM), a magnetic or optical card, or any type of media suitable forstoring electronic instructions, and each coupled to a computer systembus. A given implementation of the computing platform is software thatexecutes on a hardware platform running an operating system such asLinux. A machine implementing the techniques herein comprises a hardwareprocessor, and non-transitory computer memory holding computer programinstructions that are executed by the processor to perform theabove-described methods.

There is no limitation on the type of computing entity that mayimplement the client-side or server-side of the connection. Anycomputing entity (system, machine, device, program, process, utility, orthe like) may act as the client or the server. While given components ofthe system have been described separately, one of ordinary skill willappreciate that some of the functions may be combined or shared in giveninstructions, program sequences, code portions, and the like. Anyapplication or functionality described herein may be implemented asnative code, by providing hooks into another application, byfacilitating use of the mechanism as a plug-in, by linking to themechanism, and the like.

The platform functionality may be co-located or various parts/componentsmay be separately and run as distinct functions, perhaps in one or morelocations (over a distributed network).

One preferred implementation of the detector is in a managed servicesuch as a content delivery network (CDN) or, more generally, an “overlaynetwork” that is operated and managed by a service provider. The serviceprovider typically provides the content delivery service on behalf ofthird parties (customers) who use the service provider's sharedinfrastructure. A distributed system of this type typically refers to acollection of autonomous computers linked by a network or networks,together with the software, systems, protocols and techniques designedto facilitate various services, such as content delivery, webapplication acceleration, or other support of outsourced origin siteinfrastructure. A CDN service provider typically provides servicedelivery through digital properties (such as a website), which areprovisioned in a customer portal and then deployed to the network. Adigital property typically is bound to one or more edge configurationsthat allow the service provider to account for traffic and bill itscustomer.

What is claimed is as follows:
 1. A method to mitigate automated attacksdirected to a computing platform environment, comprising: uponoccurrence of a transaction associated with an automated scriptconfigured to initiate an actual automated attack on the computingplatform environment, detecting whether the transaction is associatedwith testing of the automated script; upon a detection that thetransaction is associated with testing of the automated script,executing the automated script in the computing platform environment;generating an indication that the automated script executed correctly;thereafter, identifying a subsequent use of the automated script in thecomputing platform environment; and responsive to identifying thesubsequent use, blocking or mitigating operation of the automatedscript.
 2. The method as described in claim 1 carried out as a managedservice.
 3. The method as described in claim 1 wherein detectingincludes performing a set of one or more detections to detect whetherthe transaction is associated with testing of the automated script. 4.The method as described in claim 3 wherein the set of detections includeone of: a transaction rate check, a user history check, an IPaddress/location check, a behavior check, and an analytical check. 5.The method as described in claim 4 wherein the detection is based on anaggregate analysis of the set of one or more detections.
 6. The methodas described in claim 5 wherein the aggregate analysis implements astatistical or machine learning algorithm.
 7. A computer program productin a non-transitory computer readable medium comprising computer programinstructions executable in a computing platform environment by ahardware processor to: upon occurrence of a transaction associated withan automated script configured to initiate an actual automated attack onthe computing platform environment, detect whether the transaction isassociated with testing of the automated script; upon a detection thatthe transaction is associated with testing of the automated script,execute the automated script in the computing platform environment;generate an indication that the automated script executed correctly;thereafter, identify a subsequent use of the automated script in thecomputing platform environment; and responsive to identifying thesubsequent use, block or mitigate operation of the automated script. 8.The computer program product as described in claim 7 wherein thecomputer program instructions that detect includes instructions furtherconfigured to perform a set of one or more detections to detect whetherthe transaction is associated with testing of the automated script. 9.The computer program product as described in claim 8 wherein the set ofdetections include one of: a transaction rate check, a user historycheck, an IP address/location check, a behavior check, and an analyticalcheck.
 10. The computer program product as described in claim 9 whereinthe detection is based on an aggregate analysis of the set of one ormore detections.
 11. The computer program product as described in claim10 wherein the aggregate analysis implements a statistical or machinelearning algorithm.